\chapter{Portage de Explorer3D}

\section{Possibilité du portage d'Explorer3d sous R}

\paragraph{}
A présent que les outils mis à disposition par RGL et RGtk2 ont été détaillés et que ceux qui restent à développer ont été analysés, nous pouvons répondre à la problèmatique principale de notre étude. Le logiciel Explorer3d est portable sur le langage R. Mais cette portabilité implique de réaliser des modifications minutieuses si l'on souhaite reproduire l'intégralité des fonctionnalités mises à disposition par Explorer3d tout en gardant la portabilité offerte par le langage R. Nous allons rappeler ces  modifications à effectuer dans la section suivante.

\paragraph{}
En contrepartie de cet inconvénient qui imposerait un développement en R voire en C de ces outil, la majorité des algorithmes d'études statistiques mis en place dans Explorer3d est déjà présente nativement dans le langage R. Il s'agit d'un facteur dont il faudra tenir compte lorsque la mise en place d'Explorer3d sous R sera effectuée.



\section{Portage RGL}
\subsection{Ce qui est fait}

\paragraph{}
Nous allons maintenant revoir ce qui a été réalisé en RGL. Nous ne nous sommes pas attardés sur les fonctions de gestion des éléments de la scène. En effet ceux-ci sont simple à prendre en main et sont détaillés dans les premieres parties de ce rapport. 

\paragraph{}
Comme nous l'avons vu dans les exemples du chapitre consacré au fonctionnement des interactions de RGL, la majorité des fonctionnalités de Java3d utilisées par Explorer3d sont accessible par RGL. Certaines ne sont pas tout a fait similaires mais peuvent être modifiées. 

\paragraph{}
Nous avons détaillé le fonctionnement du principal outils de sélection et comment traiter les résultats de cette sélection. Plusieurs possibilités de rendu ont également été examinées afin de pouvoir se plier aux exigences de l'utilisateur. Nous avons également pu étudier le fonctionnement et l'inconvénient de l'animation.

\newpage
\subsection{Ce qui reste à faire}

\paragraph{Les limites de RGL}
\paragraph{}
Un problème majeur qui apparait à ce point est qu'une fonctionnalité importante d'Explorer3d ne pourra pas être reproduite en R. En effet sous Explorer3d deux types de sélection d'éléments existent : la sélection de région d'éléments et la sélection d'un unique élément. Comme nous avons pu le voir  la sélection d'un élément unique est gérée dans RGL par Selectpoints3d. Or Selectpoints3d ne permet pas une selection individuelle d'éléments différents de plots3d, ce qui ne correspond pas aux spécificités que nous recherchons pour porter Explorer3d sous R.

\paragraph{}
Une solution à ce problème serait de surcoucher une nouvelle fonction de sélection via Select3d. Par exemple, lors d'un événement défini une selection via Select3d sera effectuée sur une zone très rèduite autour de l'unique élément ciblé. Théoriquement cette fonctionnalité est réalisable. L'inconvénient est qu'il n'y aurait pas un unique élément sélectionné, mais tout les éléments compris dans cette même sélection (alignés en profondeur avec l'élément ciblé).

\paragraph{}
Un autre problème se pose toutefois au niveau de RGL. Comme nous l'avons également évoqué au chapitre précédent, la loupe présente dans Explorer3d est réalisable en R. Mais cette réalisation nécessite d'effectuer des modifications dans les codes sources de RGL - voire de R puisque nous devons accèder aux fichiers C sur lesquels est basé R. RGtk2 offre toutefois des outils qui pourraient complémenter le manque de certaines fonctionnalités de RGL, comme nous l'avons détaillé.

\paragraph{Maintenir la portabilité de R}
\paragraph{}
Ces deux problèmes que nous avons abordé soulèvent à leur tour un inconvéniant majeur. En effet, si ces deux fonctionnalités venaient à etre implémentées, nous perdrions l'un des avantages qui a conduit à choisir R comme langage sur lequel porter Explorer3d : la portabilité de R lui-même. L'objectif de porter Explorer3d sous R est que tout les utilisateurs de R puissent utiliser ce logiciel à partir du moment où il y ont accès, sans avoir à altérer leur version de R. C'est au final un problème important et dont il faudra tenir compte lorsque cette portabilité d'Explorer3d sous R sera poursuivie.


\newpage 
\section{Portage RGtk2}
\paragraph{}
Nous l'avons déjà évoqué, mais le portage d'Explorer3D sous R est envisagé pour permettre à ce logiciel d’être accessible à la communauté, qui dans le domaine de la classification utilise majoritairement R. Nous l'avons vu dans les parties précédentes, RGtk2 répond favorablement aux besoins d'interface utilisateur. Nous avons donc commencé le portage de l'application Explorer3D vers R.

\subsection{Ce qui est fait}
\paragraph{}
Nous allons maintenant parler de ce que nous avons eu le temps d'implémenter. Nous l’avons déjà vu, le plus difficile avec RGtk2 n'est pas de savoir si un composant dont on a besoin existe, mais plutôt d'apprendre comment répondre à ce besoin, autant en terme de composant qu'en terme d'événement.

\paragraph{}
Nous avons fait une grande liste de tous les composants graphiques nécessaires par panel, de toute l'application, et nous les avons implémentés. Tous sauf deux cas particuliers dont nous n'avons pas eu le temps d'explorer les widgets nécessaires à leur création, c'est à dire comment le créer et le configurer ou tout simplement nous ne savons pas comment, ni avec quels objets résoudre la demande.

\paragraph{}
Pour résumer, nous avons presque tout implémenté au niveau de l'interface, à quelques fenêtres de dialogue prêt, par manque de temps et d'exploration, et surtout parce que se sont des fenêtres qui s'ouvrent uniquement en cliquant dans certains menus, nous nous sommes donc concentrés sur le reste de l'interface. Mais tout les panels du panel de contrôle d'Explorer3D sont implémentés.

\newpage
\paragraph{}
Ci dessous le panel de contrôle d'Explorer3D.

\begin{center}
\includegraphics[scale=0.7]{panelGauche.png}
\end{center}

\paragraph{}
Nous constatons que les conteneurs sont remplis avec plusieurs composants différents, mais nous avons montré que ce n'est pas vraiment un problème de recréer cette interface avec RGtk2. Le seul point qu'il nous reste à trouver est que dans le panel gauche précédemment cité, tous les sous-conteneurs sont pliables/dépliables, alors que dans notre version, nous n'avons pas trouvé de conteneur qui réalisait cela directement. Nous savons que nous pourrions recoder nous même ce panel à la main, en utilisant des boutons et une fonction qui affiche ou efface les objets lors du clic. Nous n'avons pas exploré cet aspect, toutefois RGtk2 propose tous les outils nécessaires pour le faire.

\paragraph{} 
Dans la figure suivante vous pouvez apercevoir le résultat, en RGtk2. Comme Gtk utilise le thème du système, le résultat est graphiquement différent de la version de base, toutefois la mécanique reste la même.

\begin{center}
\includegraphics[scale=0.5]{panelGaucheR.png}
\end{center}

\paragraph{}
On constate que certes l'affichage est quelque peu différent, toutefois les composants (boutons, listes, labels, etc...) sont bien tous présents. De plus, nous avons reproduit le comportement du logiciel initial, c'est à dire que les sous-conteneurs affichés changent dynamiquement en fonction du menu. Dans RGtk2 nous le faisons aussi et ce n'est pas une difficulté car chaque composant a un attribut visible, un booléen qu'il suffit de mettre à FALSE pour cacher le composant et TRUE pour qu'il soit visible.

\paragraph{}
Il est difficile de faire une démonstration du comportement dynamique dans un rapport papier. Toutefois, nous avons testé notre code et le fonctionnement reprend celui d'Explorer3D. Nous n'avons évidemment pas eu le temps de tout porter sous RGtk2. Nous allons donc maintenant parler des points qu'il reste à développer.
\newpage

\subsection{Ce qui reste à faire}
\paragraph{}
Nous avons bien avancé dans la programmation en RGtk2, toutefois, le portage d'un logiciel comme Explorer3D (qui a plusieurs années de développement derrière lui) est une tâche conséquente, et nous n'avons pas terminé. Nous allons mettre en évidence les choses qui sont en cours mais non terminées ou que nous n'avons pas abordées.

\paragraph{}
Tout d'abord graphiquement, il ne reste pas beaucoup de choses à faire, en effet, la plupart des composants graphiques requis pour le projet sont faits. Toutefois, il reste certains cas particuliers qui n'ont pas été implémentés. Par exemple, nous ne nous sommes pas penchés sur le moteur de calcul, car nous l'avons déjà évoqué, les principales fonctions de calcul (par exemple acp) sont déjà implémentées en R, il ne reste donc qu'à les lier aux différents boutons.

\paragraph{}
Encore une fois par manque de temps, nous rendons donc une interface presque complète, à laquelle il manque le panel "explorateur" d'Explorer3D, le panel Observation aussi, que nous pouvons apercevoir dans la figure suivante.
\begin{center}
\includegraphics[scale=0.5]{panelsManquants.png}
\end{center}

\paragraph{}
Ces deux panels n'ont pas été implémentés car leur fonctionnement ne nous est pas familier. De plus nous n'avons pas trop apporté d'élément de réponses pour créer ces panels. Pour le moment, certaines fonctionnalités ont été implémentées : certains boutons sont connectés à des fonctions et la plupart des menus engendrent les comportements attendus.

\paragraph{}
Toutefois, cette étape de remplissage n’est pas terminée car il va falloir lier les éléments qui ne ne le sont pas encore. De plus, nous l'avons déjà évoqué, le moteur de calcul et les fonctions de classification nécessaires dans Explorer3D sont déjà présentes en R. Il ne reste qu'à les appeler dans les fonctions qui seront connectées aux boutons. 

\paragraph{}
Nous avons vu que le portage était bien avancé, mais pas totalement terminé. Même si il est un peu tôt pour en parler, nous allons pouruivre sur les extensions possibles pour le logiciel.